DevOps の第 2 の道 : フィードバックの原則
『The DevOps ハンドブック 理論・原則・実践のすべて』 より
バリューストリームの全てのステージで、右から左にコンスタントにフィードバックを返せるようにすること
複雑なシステム (複雑系？) の特徴
システム全体を把握して全ての部品がどのように関連しているか誰にも理解できない
同じことを 2 度しても、必ずしも同じ結果にはならない
安全文化の重要な要素の体系化をした Sidney Dekker 博士による観察
複雑なシステムではエラーは必然で不可避 → 生産でも IT でも破滅的な悪影響のはるか手前で障害を発見できる自信が必要
複雑なシステムで安全に作業する条件 (Steven Spear 博士のトヨタ生産方式に関する博士論文より)
1. 設計や運用の問題が明らかになるように複雑な仕事を管理する
フィードバックループとフィードフォワードループ
学習する組織とシステム思考にフィードバックループが重要 (『The Fifth Discipline : The Art and Practice of the Learning Organization』 (『最強組織の法則』))
プロセス上の、全ての作業の測定、モニタリング
本番環境での IT システムのモニタリング
Elisabeth Hendrickson 「品質保証部門の長だったときの自分の仕事は、フィードバックサイクルを生み出すこと」
2. 問題が発生したときに組織一丸で解決にあたり、新しい知識を素早く構築する
トヨタのアンドンが好例
W. Edwards Deming によって広く知られる Shewhart サイクルの PDCA の加速版
何か問題が起きた時に周りの作業を止める文化を作ることが大事
3. 組織の一部が獲得した局所的な知識を、組織全体で活用する
4. リーダーが、この種の能力を継続的に成長させていくような人を次のリーダーとして育てていく
上流での品質確保の追求
全ての人が品質に責任を持つように
1980 年代の製造性重視設計 (Designing for Manufacutuability)
IT バリューストリームにおいては、開発にとっての最重要な顧客は運用
4 部 第 2 の道 : フィードバックの技術的実践
14 章 問題の可視化と解決のための基礎となる遠隔測定データを作り出す
因果関係の文化
遠隔測定
Graphite 利用の例
運用のモニタリングとロギングはずっと昔から一般的だったが、情報はサイロ化していた
開発は開発者が関心をもつイベントだけロギングし、運用は環境が落ちていないかどうかしか監視しない
システムが全体としてどう振る舞っているかを十分に理解できるだけの遠隔測定データを生成する必要がある
モニタリングフレームワーク
アプリケーションロギングライブラリの例 : Java の rrd4j、log4j、Ruby の ruby-cabin など
遠隔測定データを簡単に作れるインフラストラクチャとライブラリを用意する (日常的に指標を簡単に作成できるように)
遠隔測定ライブラリの例 : StatsD、JMX、Codahale Metrics
問題解決のための指標作成ツールの例 : New Relic、ApDynamics、Dynatrace
その他、モニタリング、データの集計や収集に役立つツールとしてアプリケーションパフォーマンスモニターと呼ばれるものがある
情報ラジエーター : 遠隔測定データの可視性を高める (開発や運用の作業空間の中心に表示して、サービスがどのように実行されているかを全員がみられるように)
遠隔測定の穴があると、インシデントの発見が遅れる
あらゆるレベルに十分な遠隔測定手段を張り巡らせる必要
ビジネスレベル : 売買取引の数や解約率、A/B テストの結果など
ビジネス指標は顧客獲得ファネルの一部
アプリケーションレベル : トランザクション数、ユーザー数、アプリケーションエラーなど
インフラストラクチャレベル : サーバーのトラフィック、CPU 負荷、ディスク利用状況など
クライアントソフトウェアレベル : アプリケーションのエラー、クラッシュ、ユーザーが測定したトランザクション数など
デプロイパイプラインレベル : ビルドパイプラインのステータス、デプロイリードタイム、デプロイの頻度など
ビジネスの指標とアプリケーションやインフラストラクチャの指標を並べてグラフを描くことで、何が起きているか理解しやすくなる
ビジネス指標はインフラストラクチャ指標のコンテキストを生み出すので、開発と運用が協力しやすくなる
運用がダウンタイムを計測するのではなく、開発と運用でダウンタイムがビジネスにどう影響を与えたかを測定する
本番だけでなく、本番より前の環境での (開発環境や、テストやステージング環境) 遠隔測定データも必要
システム変更には本質的にリスクがある → グラフに本番デプロイの全ての工程を重ね合わせて表示すべし
15 章 遠隔測定データを分析して問題の予測と目標の達成に活かす
本書のこれ以降では、遠隔測定データと指標とデータセットの 3 つの言葉を交換可能なものとして扱う
外れ値検出 (outlier detection)
単純な統計テクニック : 平均 (mean、average)、標準偏差 (standard deviation)
アラートを上げる際にどんな指標を見るべきか？ → 実際に起こった障害に対して、どの指標を見ていれば事前検知できたか？
運用では、多くのデータセットがカイ二乗分布と呼ばれる分布になる
それに対して標準偏差を使うのはナンセンス
異常値検出 (anomaly detection)
Rally Software では、本番システムの各種指標を Tableau に入れている
平準化 (smoothing)
移動平均やローリング平均
ユーザーデータに関する遠隔測定の大部分は周期的だったり季節的な類似性がある
KS 検定
16 章 フィードバックループを実現して開発と運用が安全にコードをデプロイできるようにする
バリューストリームの上流が自部門の都合で動くとバリューストリーム全体のパフォーマンスを低下させうる (例 : インシデント)
運用上のインシデントの処理を、バリューストリーム全体で共有する
開発者、開発マネジャー、アーキテクトもオンコールに参加させる
UX 設計におけるコンテキスト調査と同じことを、社内の顧客に対しても行う
開発者に、下流の様子を観察させる
サービスハンドバックの仕組み
17 章 日常業務に仮説駆動開発と A/B テストを組み込む
機能を作っては作りっぱなしで、効果を検証しないことが多い
機能を作る前に、本当に作るべきかを深く考えるべき
A/B テスト
実験的なアプローチのために、仕事を小さなユニットに分割するだけでなく、それぞれのユニットが期待された結果を生み出すかどうかをチェックする必要
18 章 レビューと調整プロセスによって現在の仕事の品質を上げる
変更諮問委員会のような役割が変更を管理するのは意味がない
詳細を見ようとすると時間がかかりすぎるし、概要把握だけではほぼ効果がない
ピアレビューを行うように (コードの変更に対してはコードレビューとして定着しているが、コード変更以外でも同様)
ペアリング (ペアプログラミング的なペア作業)